15.1 KB · ⇊ 5 parts · ⤓ Micron 15.1 KB · ⤓ HTML 26.6 KB

top

In mwawinformatica, in particolare nell'mwbaingegneria del software, gli mwbqanti-pattern (o antipattern) sono dei mwbgmwbwdesign pattern, o, più in generale, delle procedure o modi di fare, usati durante il processo di sviluppo del software che, pur essendo lecitamente utilizzabili, si rivelano successivamente inadatti o controproducenti nella praticacite-ref-1[1]cite-ref-2[2]. Il termine fu coniato nel 1995 da Andrew Koenig, ispirato dal libro mweamweqDesign Patterns: Elementi per il riuso di software ad oggetti scritto dalla mwegGang of Four (la banda dei quattro), i quali svilupparono il concetto di pattern nel campo del software.

Fu, tuttavia, il libro mwfaAntiPatterns del 1998 a rendere popolare l'idea e ad ampliarne l'ambito oltre il campo del design del software, includendo anche l'architettura software e la gestione dei progetticite-ref-0-3-0[3]. Successivamente, altri autori hanno ulteriormente esteso il concetto per abbracciare antipattern ambientali, organizzativi e culturalicite-ref-0-3-1[3].

• Definizione

• Uso

• Gli anti-pattern più comuni

• Note

• Bibliografia

• Altri progetti

• Collegamenti esterni

Secondo gli autori, devono presentarsi almeno due elementi chiave per poter distinguere un anti-pattern da un semplice errore logico o cattiva abitudine:

• Qualche schema ricorrente di azioni, processi o strutture che inizialmente appaiono essere di beneficio, ma successivamente producono più problemi che benefici.

• L'esistenza di una soluzione alternativa che è chiaramente documentata, collaudata nella pratica e ripetibile, ma che non viene adottata.

Molti anti-pattern sono poco più che errori, problemi irrisolvibili o cattive pratiche da evitare quando possibile. A volte chiamati "pitfalls" (tranelli) o mwjamwjqdark pattern (modelli oscuri) se invece sono volutamente ingannevoli, si riferiscono a classi di soluzioni di problemi reinventate in modo sbagliato.

Una guida comunemente utilizzata è la "regola del tre," simile a quella per i pattern: per essere considerato un antipattern, deve essere stato osservato almeno tre volte.cite-ref-0-3-2[3]

Per prevenire errori che tendono a ripetersi, si può individuare la frequenza con la quale questi si ripetono, e imparare come altre persone hanno rimediato a questi cattivi pattern.

Documentare gli antipattern può essere un metodo efficace per analizzare un ambito problematico e raccogliere conoscenze esperte.cite-ref-4[4]

Sebbene alcune descrizioni di antipattern si limitino a documentare le conseguenze negative del pattern, una buona documentazione di un antipattern fornisce anche un'alternativa o un modo per attenuarlo.

(Nota: il nome in inglese è stato lasciato in quanto è quello con cui i pattern, e gli anti-pattern, sono conosciuti nella mwnqlingua italiana)

• Progettazione orientata alla commissione (mwogdesign by committee): presenza di molte persone che contribuiscono a una progettazione, ma mancanza di una visione globale condivisa

• Corpi tiepidi (mwpawarm bodies): aggiungere a un progetto nuovi programmatori che non riusciranno a fare quasi nulla per mancanza di esperienza su di esso

• Paralisi da analisi (mwpganalysis paralysis): progetto fermo nella fase di analisi, ad esempio perché si sta vagliando un ventaglio di soluzioni troppo ampio senza riuscire a sceglierne una, o perché la si sta dettagliando eccessivamente

• Sistema a tubo da stufa (mwqastovepipe system): organizzazione in cui ogni team è isolato dagli altri, e le comunicazioni sono rese possibili solo verso l'alto o il basso della gerarchia

• Fumo e specchi (mwrqsmoke and mirrors): mostrare una funzionalità del programma che in realtà non esiste ancora, ad esempio tramite schermate fittizie, senza che l'osservatore sappia che lo sono

• Gestione a fungo (mwrwmushroom management): team in cui ogni impiegato è tenuto isolato, con un compito specifico, senza poter comunicare con i compagni

• Marcia della morte (mwsqdeath march): progetto i cui vantaggi sono troppo scarsi rispetto alle risorse richieste per svilupparlo, che costringe i programmatori a sforzi pesantissimi e a un numero consistente di ore di straordinario, ma che è comunque destinato a fallire

• mwswElefante nella stanza (mwtaelephant in the room): ignorare o minimizzare un problema anche se ovvio e appariscente, al fine di evitarlo

• Ancora di nave (mwuqboat anchor): mantenere una porzione di mwugcodice sorgente diventata inutile

• mwvamwvqBusy waiting: ciclo continuo di attesa di un evento

• mwvwAzione a distanza (mwwaaction at a distance): modifica che impatta su parti di codice molto lontane tra loro

• Errore di mwwgcache (mwwwcaching failure): non azzerare o svuotare una cache contenente un errore, dopo che è stato risolto

• mwxqCarica e spara (mwxgaccumulate and fire): mwxwsubroutine i cui input sono variabili globali

• Codice maleodorante (mwyqcode smell): piccolo malfunzionamento, che però è sintomo di un grande problema più nascosto

• Colata di lava (mwywlava flow): mantenere porzioni di codice la cui rimozione è rischiosa o può causare conseguenze non determinabili

• Complessità involontaria (mwzqaccidental complexity): apparente necessità di sviluppare codice complesso, che invece sarebbe già disponibile in qualche libreria

• Enorme palla di fango (mwzwbig ball of mud): sistema costruito in modo caotico, senza una struttura riconoscibile

• Fede cieca (mwaqblind faith): non verificare il risultato di una funzione o il manifestarsi di un errore

• Inerzia del codice (mwawcode momentum): presenza eccessiva di vincoli e dipendenze, che rendono difficili le modifiche

• Inferno delle mwbqDLL (mwbgDLL hell): presenza di conflitti tra le DLL da cui il programma dipende

• Nelle mani del fornitore (mwcavendor lock-in): dipendenza troppo stretta da uno specifico fornitore, non sostituibile se non a costi elevati

• Input ad-hoc (mwcginput kludge): incapacità di gestire dati inseriti nell'interfaccia utente (input) non validi

• mwdaInterblocco ricontrollato (mwdqdouble-checked locking): inizializzazione parziale di un oggetto condiviso tra thread

• Interfaccia enorme (mwdwinterface bloat): incorporare troppe operazioni in una sola interfaccia

• mweqInvecchiamento rapido (mwegcontinuous obsolescence): sistema le cui nuove versioni sono troppo diverse dalle precedenti, e che quindi invecchia rapidamente e di continuo

• mwfaInversione di astrazione (mwfqabstraction inversion): non esporre funzionalità utili, costringendo a reimplementarle

• mwfwKitchen sink: oggetto che contiene un gran numero di operazioni complesse ed eterogenee tra loro

• mwgqNumero magico (mwggmagic number): inserire costanti negli algoritmi senza documentarne il significato o lo scopo

• mwhaOggetto Dio (mwhqGod object): implementare una grossa funzionalità in un unico oggetto che esegue tutte le operazioni, invece che in più oggetti che si dividono il compito;

• Ottimizzazione prematura (mwhwpremature optimization): scrivere codice molto ottimizzato, ma poco leggibile

• mwiqPoltergeist: oggetto il cui unico compito è passare informazioni a un unico altro oggetto

• Priorità alle estensioni (mwiwfeature creep): aggiungere ulteriori caratteristiche al progetto, andando ben oltre il requisito iniziale

• Problema dello yo-yo (mwjqyo-yo problem): struttura eccessivamente frammentata e quindi difficile da comprendere

• mwjwProgrammazione cargo cult (mwkacargo cult programming): inserire una porzione di programma ignorandone scopo o principio di funzionamento

• Programmazione mwkgcopia e incolla (mwkwcopy and paste programming): implementare una funzionalità simile ad un'altra copiandone e incollandone il codice piuttosto che creando una subroutine condivisa

• Pulsante magico (mwlqmagic pushbutton): pulsante che contiene anche la propria logica applicativa, invece che tenerla separata

• Punto di vista ambiguo (mwlwambiguous viewpoint): diagramma che indica solo le parti, ma non cosa compongono, ad esempio senza distinguere tra parti di interfaccia e di implementazione

• mwmqReinventare la ruota (mwmgreinventing the wheel): reimplementare un metodo che è già stato implementato, testato e ottimizzato da qualcun altro

• Reinventare la ruota quadrata (mwnareinventing the Square Wheel): come mwnqreinventing the wheel, ma il risultato della reimplementazione è peggiore del metodo esistente

• Saltare il primo (mwnwFencepost o anche mwoaoff-by-one error): partire dall'indice iniziale sbagliato in un loop (ad esempio in Java iniziare il loop su un array partendo da 1 invece che da 0, o contare un intervallo di valori escludendo il primo, tipicamente il numero di giorni di validità compreso fra due date dimenticando che il primo giorno va considerato)

• mwogSoftware che ingrassa (mwowsoftware bloat): tendenza di un'applicazione ad avere programmi di installazione che crescono a dismisura

• mwpqSpaghetti code (mwpgspaghetti code): codice con un flusso incomprensibile

• mwqaCodifica fissa (mwqqhard code): inserire costanti nel codice piuttosto che in file di configurazione

• Valori esterni (mwqwsoft code): inserire logica applicativa in file di configurazione (ad esempio con un linguaggio di comandi) piuttosto che nel codice

• mwrqVicolo cieco (mwrgDead End): dover modificare una componente su cui il supporto da parte di chi l'ha fornita è cessato

cite-note-11. ↑ mwtqAmbler, Scott W., mwtgProcess patterns: building large-scale systems using object technology, 1998, p.mwtw 4, mwuaISBNmwuq 0-521-64568-9. mwva«...common approaches to solving recurring problems that prove to be ineffective. These approaches are called antipatterns.»

cite-note-22. ↑ mwwaBudgen, D., mwwqmwwgSoftware design, 2003, p.mwww 225, mwxaISBNmwxq 0-201-72219-4. mwya«As described in Long (2001), design anti-patterns are 'obvious, but wrong, solutions to recurring problems'.»

cite-note-0-33. ↑ mw0aColin J. Neill, Phillip A. Laplante e Joanna F. DeFranco, mw0qAntipatterns: managing software organizations and people, collana mw0gApplied software engineering series, 2nd ed (Online-Ausg.), CRC Press/Auerbach Publications, 2012, pp.mw0w 4-6, mw1aISBNmw1q 978-1-4398-6216-2.

cite-note-44. ↑ mw2gEdward Jimenez, mw2wmw3aAntiPatterns, aprile 2006.

• William J. Brown, Raphael C. Malveau, Hays W. McCormick III, e Thomas J. Mowbray. 1998. mw4aAntiPatterns: Refactoring Software, Architectures, and Projects in Crisis. mw4qJohn Wiley & Sons ISBN 0-471-19713-0.

Altri progetti

• Wikimedia Commons

• Wikimedia Commons contiene immagini o altri file sull'anti-pattern

• mw5whttp://www.antipatterns.com